SharePoint 2010 : Making Enterprise Content Management Work - Document Management (part 1) - Item-level Security, Versioning Settings

Technically, document management has been a core piece of SharePoint since its inception, with features such as Document Libraries and Custom Columns (Metadata). Some might argue that prior versions of SharePoint offered “document collaboration” or perhaps document management “lite.” The new document management features that have been added in SharePoint 2010 bring SharePoint’s document management capabilities up to par with industry standards. This section discusses each of the key document management features, how and when you’d use them, and then provides a step-by-step walkthrough of configuring a typical configuration for document and records management within SharePoint.

1. Document Libraries

A document library is simply a SharePoint list that is designed to accommodate documents. In SharePoint, libraries are designed to hold large items such as documents, images, videos, and reports, while lists typically hold structured data. In most cases, a document library provides the best place to store and manage document content, with features such as versions, check-in/out, and tagging.

2. Item-level Security

One of the features introduced in SharePoint 2007 was the ability to configure permissions at the item level. This prevented administrators from having to create more document libraries. Why? Without item-level security, all documents in a document library were under the same security rule. This meant that outliers were forced into separate document libraries with unique security definitions. Not only did this make little sense to end users (who had to look for similar documents in multiple locations), but it also meant the replication and maintenance of dual metadata lists. This was both cumbersome and confusing.

WSS 3.0 introduced item-level security, which allows items and folders to be managed at the item level. This means that a single document library can hold a collection of similar (by content) documents that have different security definitions. Users looking at the list may see different documents based on their security privileges. In addition, security can be applied not just for viewing but for editing as well. In this case, specific users can edit only certain documents in the list. Again, one document library manages a collection of similar content, but the visibility or accessibility is being managed at the item level.

However, even though you can secure content at the item level, our recommendation is to use item-level security as little as possible due to the administrative burden that it puts on site administrators.

3. Versioning Settings

Version management is a core component of any document management system. It involves tracking the history associated with each group of changes made to a particular document. Like SharePoint 2007, SharePoint 2010 offers the ability to keep no prior versions, major versions only, or major and minor versions. A major version number is associated with a version that has been published. A minor version number is associated with a version that is in progress, will be published, but is not yet published. SharePoint tracks changes to both content inside a document and to the document’s metadata properties.

Major and minor versioning is an option for documents (and other list items) under the Versioning Settings for a document library. Here, you can determine whether items should have major versions only (or minor versions as well), how many versions of each type to keep, and the visibility of minor documents. See Figure 1. Let’s discuss each of these in more detail.

Figure 1. The Document Library Versioning Settings provide content approval, version history, draft item security, and check-out requirement options for a document library

Content Approval

There are a number of versioning settings to discuss, the first of which is Content Approval (see Figure 2). You can think of this setting as a one-stage approval process. When this setting is enabled, all major-versioned documents need approval from a particular user role before they can be seen by most users. New and changed items remain in a pending state until they are approved or rejected by someone who has permission to approve them. If an item or file is approved, it is assigned an Approved status in the list or library, and it is displayed to anyone with permission to view the list or library. If the item or file is rejected, it remains in a pending state and is visible only to the people with permission to view drafts. Minor versions (drafts) don’t require approval. These settings apply to what gets returned in search results as well; if you don’t have permissions to see “pending” items, they will not be returned in the search results.

Figure 2. Content approval enables you to require major versions of items to be approved before they are visible

Document Version History

Depending on the options selected in this section of your library settings, SharePoint will track revisions to items in this library or list. Libraries can track both major and minor versions. Lists and libraries can also limit the number of versions that people can store (see Figure 3).

Figure 3. Versioning enables you to save the various changes to an item over the course of its editing history

Tracking both major and minor versions provides a more detailed way to track the version history of an item. Major versions are more likely to represent a milestone, such as when a file is ready to be viewed by a wide audience. A minor version is typically used as a routine increment, such as a version that a user saves or checks in while he or she is still writing the content. When you want to view the version history of a document, major and minor versions make it easy to identify the stages of the document’s development.

When versioning is enabled, versions are stored by default as a minor versions unless you designate them as major versions. When users save a file and close it, the version is tracked as a minor version. Users must publish the item in order for it to become a major version.

If you check out files before working on them, you can designate which type of version you are checking in. You do not have to publish a file if you designate it as a major version when you check it in.

Versions are numbered when they are created. When tracking major and minor versions, the major versions are whole numbers, and the minor versions are decimals. For example, when you first create or upload a document, the document is versioned as 0.1. If you revise it, the document becomes 0.2 (then 0.3 and so on) until you first publish it to create version 1.0. The next revision cycle creates version 1.1, 1.2, 1.x ... until you publish its next major version (2.0).

Let’s walk through an example to illustrate how the version numbering might work. Let’s assume that a user creates a new file in a document library; the document is labeled 0.1. When the user publishes the document, it is then labeled version 1.0. When that document is checked back into the document library, version 1.1 is visible to team members but not seen by the organization. (Note that the specific visibility of draft items depends on the Draft Item Security setting, described in the next section.) The rest of the organization continues to see only version 1.0. Same with a second draft, tagged as version 1.2. Finally, when the document is published, version 2.0 is created, and it supplants version 1.0 from a visibility perspective so that everyone sees version 2.0.

Again, let’s recap:

• Version 0.1 (created at check-in; visible to author and/or approval team only)

• Version 1.0 (created when published; visible to all after approval takes place)

• Version 1.1 (created at check-in; visible to author and/or approval team only)

• Version 1.2 (created at check-in; visible to author and/or approval team only)

• Version 2.0 (visible to all)

The power in the major/minor functionality is the ability to manage the document revision process within the portal (versus on a local drive) while at the same time ensuring that a document is not made available until complete and approved.

Note that if you choose to limit the number of versions that SharePoint stores, the oldest versions are permanently deleted when the limit is reached and not sent to the Recycle Bin.

Draft Item Security

The Draft Item Security setting enables you to control which groups of people can read drafts (see Figure 4). As discussed in the previous section, drafts are the minor versions of a file and are created in one of two ways: either when a minor version of a file is created or updated in a library that tracks major and minor versions, or when a list item or file is created or updated but is not yet approved in a list or library in which content approval is required.

Figure 4. The Draft Item Security setting enables you to control which groups of people can read drafts

You can specify which groups of people can view drafts—either by enabling all users with read access to view them or by restricting it to only users who can edit items. This enables you to specify different settings for the group of people who can view the rest of the items in your list or library, such as the major versions of files or the files or list items that are approved.

When content approval is required, you can specify whether files that are pending approval can be viewed by people with permission to read, people with permission to edit, or only the author and people with permission to approve items. If both major and minor versions are being tracked, the author must publish a major version before the file can be submitted for approval. When content approval is required, people who have permission to read content but do not have permission to see draft items will see the last approved or major version of the file.

If you plan to use minor versions and content approval, then we recommend configuring the Draft Item Security in such a way that only editors and/or approvers see draft items. This ensures that general site users don’t see unapproved versions of documents.

Require Check-out

You can also configure the document library to require check-out before items can be edited (see Figure 5). Requiring check-out prevents multiple people from making changes at the same time. When this setting is enabled, new files are initially set as checked out. The person who creates or adds the file must check it in before other people can see it. Check-out is also required to update metadata properties on the file.

Figure 5. The Require Check-out setting enables you to require check-out before items can be edited

When check-out is required, a file is checked out automatically when someone opens it for editing. When a file is checked out, no one can edit it except the person who checked it out (with the exception of coauthoring, which provides multiuser editing of the same document). Changes that someone makes to a file while it is checked out are not visible to others until the file is checked back in. This is true regardless of whether the person is working on the file locally or on the server.

When a user checks in a file, he is prompted to enter comments about the changes that he made. If a library tracks versions, the comments become part of the version history. If both major versions and minor versions are tracked, the user is prompted to choose which type of version they are checking in (major or minor).